home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12315 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.8 KB
  1. Path: news.interpath.net!usenet
  2. From: "Richard F. Albury" <richard.albury@virtus.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: Tue, 19 Mar 1996 08:56:24 -0500
  6. Organization: Virtus Corporation
  7. Message-ID: <314EBD08.43BC@virtus.com>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu> <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net> <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net>
  9. NNTP-Posting-Host: albury-win.virtus.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. >         -inline C++ functions should be in a file with the extension .icc (not
  16. > in the primary header).
  17. >         I don't think I have to say anything here either.  But, I
  18. > will.  Although I've seen many people do this, it is contrary to normal
  19. > industry practices.  By using non-standard practices you increase the learning
  20. > necessary for new employees.  Bad.
  21.  
  22. Hmm.  All the PC and Mac compilers I've seen do this.  Given a class TFoo, the
  23. class is defined in Foo.h and the inlines are in Foo.inl.  The user includes
  24. only Foo.h, allowing the implementor to move things between the files Foo.h and
  25. Foo.inl at will with minimal impact to the user.
  26.  
  27. >         -do not use the /* */ comment, except when commenting out entire
  28. > sections of code.
  29. >         /* */ are the ANSI standard comment.  // are not.  When you have a
  30. > parameter not used warning, you should eliminate it using.
  31. >         void f(int /* idControl */);
  32. > You can't do this with //.  You could also delete the identifier, but then you
  33. > would lose context.
  34.  
  35. // is the standard C++ comment, so I'm not sure I understand your objection.
  36.  
  37. >         -a class which can be instantiated with a "new" must have a copy
  38. > constructor, a destructor and an assignment operator definition.
  39. >         Most compilers (if not all) supply default copy construtors.  Unless
  40. > you think your class may have copy behavior problems, then writing copy
  41. > constructors is redundant.  When you have 100+ classes to write and where the
  42. > average copy constructor has 50 lines, you would need 100 hours to write the
  43. > additional robustness (or cumbersomeness).
  44.  
  45. It's good discipline.  Read Scott Meyers' books for more info.
  46.  
  47. >         -never use #define instead or const.
  48. >         This is a good debate, but I still maintain that if your memory model
  49. > and compiler make #define data text and const code text, then you cannot
  50. > consider this a straight forward trade-off.
  51.  
  52. Granted, there are implementation issues which in a small set of cases might
  53. make the use of const a problem, but const is typesafe, while #define is not.
  54. The whole purpose for using C++ is to attempt to adhere to the OO principles
  55. of encapsulation, abstraction, and polymorphism.
  56.  
  57. >         -every case statement must be terminated with a break statement.
  58. >         Why?  This is arbitrary and makes some programming algorithms harder
  59. > to implement.  Example: the messages handling switch statement.  You usually
  60. > break to fall to the default handling and return to skip the default handling.
  61.  
  62. The switch statement is one of C's worst "features."  Inadvertently leaving off
  63. a break can be hard to track down.
  64.  
  65. >         -optimize code only when you have a problem.
  66. >         Why not anticipate the problem?
  67.  
  68. You rarely can.  Read Plauger's writings on style.  One of his sayings is
  69. "First make it right, then make it fast."  If performance is an issue, use a
  70. profiler.
  71.  
  72. >         -access functions are to be inline.
  73. >         This is the biggest fallacy in programming today.  If you make your
  74. > accessors inline, then you have defeated the purpose of data hiding.  If your
  75. > data's type changes, then you still have to recompile every object that
  76. > accesses the member.
  77.  
  78. Agreed.
  79.  
  80. >         -give protected accessors for all data members.
  81. >         Proper encapsulation tells us otherwise.
  82.  
  83. Ditto.
  84.